Celestin Apprentice 2/Apprentice-Release2.iso/Information/Digests/CSMP Digest/volume 1/csmp-v1-168.txt

Text File | 1994-12-08 | 43.6 KB | 1,140 lines | [TEXT/R*ch]

C.S.M.P. Digest             Sun, 16 Aug 92       Volume 1 : Issue 168

Today's Topics:

    Dispose of my relocatable blocks?
    "remote" app termination
    How do I get a Spinning Watch?
    undocumented low-memory globals
    MPW on SE
    MPW Scripting Q - answer
    Debugger for daemons?
    Dragging Icons...HELP!
    DSAT error #28, ThinkPascal, and MacsBug (weird)
    When to HLock (and not HLock) handles



The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  (This means you can't post questions to the
digest.)

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
cs.uoregon.edu).  Article threads are not added to the digest until the last
article added to the thread is at least one month old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The entire digest is available for anonymous ftp from ftp.cs.uoregon.edu
[128.223.8.8] in the directory /pub/mac/csmp-digest.  Be sure to read the
file /pub/mac/csmp-digest/README before downloading any files.  The most
recent issues are available from sumex-aim.stanford.edu [36.44.0.6] in the
directory /info-mac/digest/csmp.  If you don't have ftp capability, the sumex
archive has a mail server; send a message with the text '$MACarch help' (no
quotes) to [e-mail] for more information.

The digest is also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new issue as it is created.  Sorry, back issues
are not available through the mailing list.

Send administrative mail to [e-mail].


-------------------------------------------------------

From: [e-mail] (PEGG, DAVID J)
Subject: Dispose of my relocatable blocks?
Date: 10 Jul 92 20:11:00 GMT
Organization: University of Tennessee Computing Center

I've been having trouble getting my program to quit without bombing.  I posted
a note here to find out why, and several people advised me to deallocate my
relocatable blocks. As far as I can tell, then, I need to call DisposHandle()
(or a function like DisposDialog() that calls DisposHandle() ).   Do I need to
do this for every handle?  Also, I'm told that the system will clean up some of
my memory mess upon quitting.  There's no problem with it trying to dispose of
a handle I already disposed of, is there?

Another (possibly unrelated) question: what is an F-line? I have been getting
system errors that say "bad F-line instruction."  What does that mean?

Thanks for helping out a beginner,
   -Mike

+++++++++++++++++++++++++++

From: [e-mail] (Dave Newman)
Date: Sun, 12 Jul 92 11:59:52 PST
Organization: Notable Technologies, Inc.


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (PEGG, DAVID J) writes:
| I've been having trouble getting my program to quit without bombing.  I posted
| a note here to find out why, and several people advised me to deallocate my
| relocatable blocks. As far as I can tell, then, I need to call DisposHandle()
| (or a function like DisposDialog() that calls DisposHandle() ).   Do I need to
| do this for every handle?  Also, I'm told that the system will clean up some of
| my memory mess upon quitting.  There's no problem with it trying to dispose of
| a handle I already disposed of, is there?

There's a BIG problem with disposing a handle you've already disposed. It
causes the heap's private data structures to become corrupted. This eventually
leads to a crash, often mysterious, and far removed from the cause.

As a general rule of thumb, you should always dispose of handles the moment
you know they are no longer needed and can be safely disposed of. Waiting
to "quit" time is not advisable for three good reasons:

1) You will have a large tangled web of handles to sift through and try
to write code for disposing them. You're better off tackling this problem
by disposing of them near the code that uses them.

2) Leaving handles around causes memory to "leak". Your heap eventually
fills to the point that it has no memory left and you'll crash with a
heap out of memory error.

3) At "quit" time you may not have enough memory left load the CODE
segments needed to dispose of the handles that are causing you to not have
enough memory. (Though well written programs try to see to it that the
"quit" code is always in memory just in case this sort of thing happens.)

| Another (possibly unrelated) question: what is an F-line? I have been getting
| system errors that say "bad F-line instruction."  What does that mean?

Means the CPU started executing garbage. One such cause is disposing of
a handle twice. This will result in the heap becoming corrupt. Heaps contain
data and code. Corrupted heaps often will have their handles to data and
code blocks scrambled. Eventually the OS goes to execute a code block that
isn't and *bang* you get the "bad F-line instruction" message when the CPU
starts to execute a data block.

- --Dave

- -----------------------------------------------------------
Dave Newman                 |  AOL:      AFC Tinman
Artillery Spotter           |  ALink:    TINMAN
Notable Technologies, Inc.  |  CIS:      70743,3323
Voice:    510.208.4449      |  internet: [e-mail]
FAX:      [phone]      |
- -----------------------------------------------------------

---------------------------

From: [e-mail] (Howard Modell)
Subject: "remote" app termination
Date: 10 Jul 92 16:48:59 GMT
Organization: Boeing Defense and Space Group

This is a System 6.0.x related question.

How can one application cause another application to "quit"?  I have a
situation in which one app (in this case SuperCard) is going to launch
another (MS Word), and I would like to be able to do something while
SuperCard is active to terminate Word.  Multifinder/Finder does this during
Restart and Shutdown, so there is *some* mechanism.  Can someone enlighten
me?

+---All opinions expressed are my own, and *NOT* my employers!---+
    Howard Modell, Boeing Defence & Space Group, Seattle, WA
    Email: [e-mail],  [e-mail],
         [e-mail], [e-mail]

+++++++++++++++++++++++++++

From: [e-mail]
Organization: Campus Computing Sites, University of Michigan-Ann Arbor
Date: Sun, 12 Jul 92 19:07:25 GMT

In article <howie-100792095112@134.52.54.217> [e-mail] (Howard Modell) writes:
>This is a System 6.0.x related question.
>
>How can one application cause another application to "quit"?  I have a
>situation in which one app (in this case SuperCard) is going to launch
>another (MS Word), and I would like to be able to do something while
>SuperCard is active to terminate Word.  Multifinder/Finder does this during
>Restart and Shutdown, so there is *some* mechanism.  Can someone enlighten
>me?
>
    There is no simple way to do this.  In fact, what MF does when the user
chooses "Restart/Shutdown" is a process known as "MultiFinder Puppet Strings"
where MF (what we now call the Process Manager) will go to each application
and FAKE IT into thinking that the user just choose the Quit menu item.  Then
each application quits happily.

    It is possible to duplicate the "MF Puppet Strings" using a Driver
to perform the "faking the quit" actions and then signalling the driver from
the application (and of course installing & removing it too).  Oh, the
driver would have to patch _MenuSelect & fake a mouseDown inMenuBar.


- --
- -----------------------------------------------------------------------
Leonard Rosenthol          Internet: [e-mail]
Director of Advanced Technology   AppleLink: MACgician
Aladdin Systems, inc.          GEnie:     MACgician

---------------------------

From: Jerome Chan <[e-mail]>
Subject: How do I get a Spinning Watch?
Organization: Alethea, The Twilight World!
Date: Sun, 12 Jul 92 19:57:17 GMT

  How do I change the icon to a spinning watch?

  I've looked into my system file and I don't see any watch Cursors
anywhere or acurs or curs resources. (System 7.0.1, IIsi). Is it hidden
away in ROM? What are their resource IDs??

- ---
 Fading

+++++++++++++++++++++++++++

From: [e-mail] (J Eric Bush)
Organization: The Ohio State University
Date: Sun, 12 Jul 1992 21:53:54 GMT

In article <[e-mail]> Jerome Chan <[e-mail].
edu> writes:
>  How do I change the icon to a spinning watch?
>
>  I've looked into my system file and I don't see any watch Cursors
>anywhere or acurs or curs resources. (System 7.0.1, IIsi). Is it hidden
>away in ROM? What are their resource IDs??
>

The cursor resource is located in the Finder, not in the System file.  I have
done this within applications by copying the cursors from the Finder to my
applications resource fork and then using SetCursor() from within Think Pascal.
 I don't know what it would be in Think C.  Here is some code to do it:

procedure adjust_cursor;
 var
  cursor: CursHandle;
 begin
  cursor := GetCursor(cursorID);
  SetCursor(cursor^^);
  cursorID := cursorID + 1;
  if cursorID > 305 then
   cursorID := 300;
 end;

cursorID would be a global which would initially be set to the first cursor in
your animation cycle.  You would adjust the 305 to be equal to the last number
in your animation cycle.  For this example, the cursor ID's were
300,301,302,303,304, and 305.

Eric
- --
- ------------------------------------------------------------------------------
J. Eric Bush
Internet: [e-mail]   ProLine: [e-mail]
GEnie:    KITCHEN.SINK

+++++++++++++++++++++++++++

From: [e-mail] (Jerome Chan)
Date: 12 Jul 92 22:35:31 GMT
Organization: Alethea, The Twilight World!

In article <[e-mail]> J Eric Bush,
[e-mail] writes:
>The cursor resource is located in the Finder, not in the System file.  I
have
>done this within applications by copying the cursors from the Finder to
my
>applications resource fork and then using SetCursor() from within Think
Pascal.

  Is there a way we can use the "acur" resources to do this job? Since
the spinning stopwatch is used by the finder to indicate a "Busy SIgnal",
it seems like a waste of space for each application to have their own
stopwatch cursors.

  Thanks for the reply!

- ---
 Fading

---------------------------

From: [e-mail] (Peter Creath)
Subject: undocumented low-memory globals
Date: 5 Jul 92 14:55:41 GMT
Organization: Cube Technologies

How does one determine the function of an undocumented low-memory
global?  I know I'm not supposed to use them, but I need to find out
what one does...

Please send all replies via mail, and I'll post a summary...

- ----------------------------------------------------------------------------
Peter Creath                 "When I was a boy I was told that anybody could
[e-mail]           become president; I'm beginning to believe it."
                                                           -- Clarence Darrow

+++++++++++++++++++++++++++

From: [e-mail] (Elizabeth Wylie)
Date: 5 Jul 92 21:12:35 GMT
Organization: U.C. Berkeley Open Computing Facility

Talk about flame-bait...

That's why they're called 'undocumented'.  For the most part the only way to
find out what one does is to change the values and see what happens.  You should
be very familiar with macsbug or tmon.

Why do you have to know?  C'mon, you can tell us.  :-)

- -E. Wylie

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 9 Jul 92 00:17:48 GMT
Organization: Apple Inc, Debugging Department

In article <[e-mail]>, [e-mail]
(Elizabeth Wylie) wrote:
> That's why they're called 'undocumented'.  For the most part the only way to
> find out what one does is to change the values and see what happens.  You should
> be very familiar with macsbug or tmon.
> Why do you have to know?  C'mon, you can tell us.  :-)

The other nice feature with undocumented lmg:s is that they might
suddenly disappear or change, as in System 7.1 or future releases.
To be secure concerning future platforms and PowerPC environments,
please avoid them, use API:s, and if something is missing, send
us an email because every lmg which needs to be accessed officially
should have an API.

Have fun!

Kent/DTS

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 9 Jul 92 05:22:04 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <ksand-080792171813@90.133.12.38>, [e-mail] (Kent Sandvik) writes:
> The other nice feature with undocumented lmg:s is that they might
> suddenly disappear or change, as in System 7.1 or future releases.
> To be secure concerning future platforms and PowerPC environments,
> please avoid them, use API:s, and if something is missing, send
> us an email because every lmg which needs to be accessed officially
> should have an API.

OK, here's one that comes to mind: there's no way to find menus by name,
other than by directly searching the MenuList!

I needed this for a set of MPW tools I wrote that let me set up a nicer
"Directory" menu and hierarchical custom menus in the MPW Shell.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
                       Signature tow-away zone. You have been wa

+++++++++++++++++++++++++++

From: [e-mail] (Jon W{tte)
Date: 9 Jul 92 10:58:29 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

.ac.nz> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:

   OK, here's one that comes to mind: there's no way to find menus by name,
   other than by directly searching the MenuList!

You shouldn't anyway, since the menu names changes between different
countries.

- --
         Jon W{tte, Svartmangatan 18, S-111 29 Stockholm, Sweden

### You have the Easy Access virus. This virus may cause strange sounds
### and weird keyboard behaviour when you press the shift key repeatedly.

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 10 Jul 92 17:18:38 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Jon W{tte) writes:
> .ac.nz> [e-mail] (Lawrence D'Oliveiro, Waikato University) writes:
>
>    OK, here's one that comes to mind: there's no way to find menus by name,
>    other than by directly searching the MenuList!
>
> You shouldn't anyway, since the menu names changes between different
> countries.

Here's the other paragraph from my original posting, that you forgot to
quote:

>>I needed this for a set of MPW tools I wrote that let me set up a nicer
>>"Directory" menu and hierarchical custom menus in the MPW Shell.

Custom MPW menus are set up using the Shell script commands AddMenu and
DeleteMenu. The names of the menus (and of the menu items) are chosen by the
user. My commands are intended to work as similarly as possible to AddMenu
and DeleteMenu, by allowing you to specify the names of menus and menu items.
I would *assume* that, whatever names they gave the menus, in whatever language,
they would use the same names when invoking my tools to manipulate those
menus.

Lawrence
not quite as dumb as he looks. :-)

+++++++++++++++++++++++++++

From: [e-mail] (Pete Gontier)
Date: 10 Jul 92 07:25:40 GMT
Organization: cellular

[e-mail] (Kent Sandvik) writes:
>The other nice feature with undocumented lmg:s is that they might
>suddenly disappear or change, as in System 7.1 or future releases.

When I see what MemError resolves to, I am dismayed of ever seeing
a "protected" MacOS, even in System 9.0.

>To be secure concerning future platforms and PowerPC environments,
>please avoid them, use API:s, and if something is missing, send
>us an email because every lmg which needs to be accessed officially
>should have an API.

The lack of a GetMBarHeight comes to mind. THINK C 4 had it. 5 still has
it, if you go out of your way to include headers which explicitly are
not part of the "official" group of MPW-style headers. I suppose
GhostWindow is another, but only Illustrator uses it. Probably there
are all sorts of LMGs which could stand an API.
- --
 Pete Gontier // EC Technology // [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Date: 15 Jul 92 18:53:45 +1200
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, I said:
> In article <ksand-080792171813@90.133.12.38>, [e-mail] (Kent Sandvik) writes:
>> The other nice feature with undocumented lmg:s is that they might
>> suddenly disappear or change, as in System 7.1 or future releases.
>> To be secure concerning future platforms and PowerPC environments,
>> please avoid them, use API:s, and if something is missing, send
>> us an email because every lmg which needs to be accessed officially
>> should have an API.
>
> OK, here's one that comes to mind: there's no way to find menus by name,
> other than by directly searching the MenuList!
>
> I needed this for a set of MPW tools I wrote that let me set up a nicer
> "Directory" menu and hierarchical custom menus in the MPW Shell.

Let me amend my original wish: what I really want is a way of indexing
through all the menus in each half of the MenuList. That is, I want to be
able to find all top-level menus (the ones whose titles appear in the menu bar)
by index, and I want to be able to scan all hierarchial/popup menus in the same
way. I can use the documented structure of a menu handle to pull out the menu
title and check it myself.

Lawrence D'Oliveiro                       fone: [phone]
Computer Services Dept                     fax: [phone]
University of Waikato            electric mail: [e-mail]
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
This disclaimer that this posting represents the sole viewpoint of
the author and not that of the University of Waikato is not the
official University of Waikato disclaimer; it is entirely the work
of the author.

---------------------------

From: [e-mail] (Paul Kohlmiller)
Subject: MPW on SE
Date: 7 Jul 92 00:22:54 GMT

I made the plunge to MPW by getting ETO. Now I see that I have to upgrade
my Mac from an SE and I've already figured out that it is better and
probably cheaper to get a MAC LC II. Fine.
I also know that my 4meg RAM on the SE is never going to work with MacAPP
and I can live with that for a while. I got MPW C to compile "hello,world".
I cannot get MPW C++ to compile the simple examples that come with it. I
get the same error that I get with MacApp - a bomb box that says the
application failed with error #2. Does this mean I can't use MPW C++ on an
SE with 4 megs? Or does this mean I did something else wrong. I am using
System 6.0.7 with and without MF. I will try system 7 as well.
All clues accepted.
BTW, an earlier post said that MPW was a career choice not a programming
choice. That was true for me, I saw the ads that asked for MPW programmers
and decided my career was somewhere down that path.
Another earlier post discussed Symantec's plans for Think C++. I'm sure that
is why (or part of why) they bought Zortech. Think C will never be C++.
There may come a time when Zortech C++ does not need MPW but life was too
short to wait so I did the ETO think.

- --
     // Paul H. Kohlmiller           //  "Cybers, Macs and Mips"      //
     // Control Data Corporation     // Internet: [e-mail]   //
     // All comments are strictly    // America Online: Paul CDC    //
     // my own.                      //                            //

+++++++++++++++++++++++++++

From: [e-mail] (Kent Sandvik)
Date: 8 Jul 92 23:36:25 GMT
Organization: Apple Inc, Debugging Department

In article <[e-mail]>, [e-mail] (Paul Kohlmiller)
wrote:
> I also know that my 4meg RAM on the SE is never going to work with MacAPP
> and I can live with that for a while. I got MPW C to compile "hello,world".
> I cannot get MPW C++ to compile the simple examples that come with it. I
> get the same error that I get with MacApp - a bomb box that says the
> application failed with error #2. Does this mean I can't use MPW C++ on an
> SE with 4 megs? Or does this mean I did something else wrong. I am using
> System 6.0.7 with and without MF. I will try system 7 as well.
> All clues accepted.

If I remember correctly the latest MPW C++ was compiled with the 68020
flags, so it won't work with 68000 based Macs. Sorry, I guess this
was an issue where the needs of the many outweighted the needs of the
few (power users vs. entry level users concerning C++). Also the
latest MPW shell is compiled with 68020 flags.

Sometimes familiarity with MPW is good for certain Macintosh oriented jobs,
however I do think that a good UNIX user should get up to speed with MPW
quickly.

I would recommend to use Think C anyway, because their object oriented
C compiler is not really C++, but it compiles and links fast on an SE.
I tried once to compile/link Nothing.cp on an SE back home, it took 34
minutes with a 4Mb SE... This was the MPW C++ 3.1, which should work
with SEs.

As for career, I think the main issue is C/C++ and any object framework
design/use. MacApp or TCL are good starting points for future other
frameworks (Bedrock, Pink, anything skanky from Seattle...).
Or do as the macho OOP programmers -- write your own framework :-).

Cheers,
Kent/DTS

+++++++++++++++++++++++++++

From: [e-mail] (Richard Harms)
Date: 14 Jul 92 07:06:17 GMT
Organization: Des Moines, Iowa, Public Access Unix; 515/277-6753

In article <ksand-080792163306@90.133.12.38> [e-mail] (Kent Sandvik) writes:
>If I remember correctly the latest MPW C++ was compiled with the 68020
>flags, so it won't work with 68000 based Macs. Sorry, I guess this
>was an issue where the needs of the many outweighted the needs of the
>few (power users vs. entry level users concerning C++). Also the
>latest MPW shell is compiled with 68020 flags.

Annoyingly, the MPW Shell which is able to use toolserver won't work on
68K machine either (I have an older portable which I used to run just the
shell on, with an older toolserver-aware mpw, and have it tell my IIfx to
compile and set the output to it... used to be convenient, but I guess that's
out now (I really wish it weren't... just a shell using a real machine to
compile code on is a good use for old 68k machines. :) ))

- -rh

- --
Richard R. Harms            Internet: [e-mail]
1217 24th, Suite 49             UUCP: {...}!{rutgers!bobsbox}!grayhawk!rich
Des Moines, Iowa 50311       AOnline: Grayhawk             AppleLink: D2656
                                 Fax: [phone]       Unix: 515/277-6753

---------------------------

From: [e-mail] (Dana S Emery)
Subject: MPW Scripting Q - answer
Date: 9 Jul 92 07:32:03 GMT
Organization: Personal

# I was being done in by some *Interesting* behaviour of the shell.

# To recap, I am attempting to port some Think C code to my Think C
# environment.  I had hoped to use MPW script to compensate for
# the unusual file disposition expected by the code.  Certain
# include "xxx" had to become #include <xxx>.  Since I am taking
# advantage of the Think search strategy which ignores folders
# whose name is (xxx) [as in Drive:Project:Source:(oldSource):WontBeSeen]
# it is necessary for me to edit the file list.

# The following skeleton shows Flow:

Directory 'Disk:Project:'
Search >'Disk:Work' /#include ../ `Files .. | Search -r /.../ | Search /.../`

#Since my home machine has a 9: screen, I broke the lines:

#  NOTE    (d => option-d)

Directory 'Disk:Project:'            # OK, but the rest fails
Search >'Disk:Work' /#include ../ d
`Files .. d
| Search -r /.../ d
| Search /.../`

# That was the source of my greifs.  The following works

Directory 'Disk:Project:'
Search >'Disk:Work' /#include ../ `Files -r -s -f -t TEXT | Search d
- -r /.../ | Search d
/.../`

# The resulting 300 lines have been printed, and are driving a semi-manual
# corection process.  I would have loved to have automated that as well,
# but I dont want to waste any more time on what murphy will throw at me
# next.  (he and I have a long relationship).

# I dont know why the line continuation upsets the interpretation of the
# pipe, perhaps it has to do with relative parseing priority of | and d, but
# it seems necessary for the pipe and the right hand *verb* to be on the same
# line as the left *verb* for the binding to take place.

# Would have been nice if this had been discussed in the manual.(sigh)

I will be glad to Email/ftp a binhex of the actual script for any one who
really wants it.

Thanks to all who responded with advice, except for the one individual
who just *had* to advocate Pearl.

- --
Dana S Emery ([e-mail])

+++++++++++++++++++++++++++

From: [e-mail] (Matthias Neeracher)
Organization: Integrated Systems Laboratory, ETH, Zurich
Date: Fri, 10 Jul 1992 16:22:21 GMT

In article <[e-mail]> [e-mail] (Dana S Emery) writes:
># That was the source of my greifs.  The following works
>
>Directory 'Disk:Project:'
>Search >'Disk:Work' /#include ../ `Files -r -s -f -t TEXT | Search d
>-r /.../ | Search d
>/.../`
>
># The resulting 300 lines have been printed, and are driving a semi-manual
># corection process.  I would have loved to have automated that as well,
># but I dont want to waste any more time on what murphy will throw at me
># next.  (he and I have a long relationship).
>[...]
>Thanks to all who responded with advice, except for the one individual
>who just *had* to advocate Pearl.

Hey, bash my advice all you want, but at least spell "Perl" right. I don't want
to be on the record as advocating a Pascal based Real Time programming language
for text searching problems.

Matthias

BTW, I still believe that Perl would be suited very well to this task.

- -----
Matthias Neeracher                                   [e-mail]
   "There once was an Age of Reason, but we've progressed beyond it."
                                   -- Ayn Rand, _Atlas Shrugged_

+++++++++++++++++++++++++++

From: [e-mail] (Steve Dorner)
Organization: Qualcomm, Inc., San Diego, CA
Date: Wed, 15 Jul 1992 03:42:14 GMT

[e-mail] (Matthias Neeracher) writes:
>In article <[e-mail]> [e-mail] (Dana S Emery) writes:
>>Thanks to all who responded with advice, except for the one individual
>>who just *had* to advocate Pearl.
>Hey, bash my advice all you want, but at least spell "Perl" right.

"Cast not thy perl before swine, lest they turn and rend you."  :-)

Matthias' MPW perl port is the best thing that could possibly have
happened to MPW.  I can live with MPW as a programming environment
now.
- --
Steve Dorner, Qualcomm, Inc.
Yes, I'm still working on Eudora and it's still free.

---------------------------

From: [e-mail] (David Peterson)
Subject: Debugger for daemons?
Date: 9 Jul 92 21:01:50 GMT
Organization: University of Southern California, Los Angeles, CA


Is there a source-level debugger (or something I can do to SADE
or SourceBug) that will let me debug faceless background apps?

I can start the thing in SourceBug and set breakpoints, but when
I try to single step all the windows go blank and I can't tell
whats going on.

SADE won't even launch a daemon.

Thanks,
- -dave.

+++++++++++++++++++++++++++

From: [e-mail] (Brian Hall)
Date: Fri, 10 Jul 92 06:36:36 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest)

[e-mail] (David Peterson) writes:


>Is there a source-level debugger (or something I can do to SADE
>or SourceBug) that will let me debug faceless background apps?

>I can start the thing in SourceBug and set breakpoints, but when
>I try to single step all the windows go blank and I can't tell
>whats going on.

This may not help much, but I found the way to debug an 'appe' in Think
C is to change the type to 'APPL' and make sure the 'background only' bit
is NOT set.  Then I use the Think Debugger as usual.  Just don't try to
run your appe when it is in this state w/o the debugger.

- --

 \ | /   | Brian Hall                 [e-mail]
 - : -   | Mark/Space Softworks       Applelink: markspace
  /|\    |                            America Online: MarkSpace
 |-+-|   |
/-\|/-\  | People don't kill people, toasters kill people.

+++++++++++++++++++++++++++

From: [e-mail] (Christoph Sold)
Organization: Universitaet Kaiserslautern
Date: Tue, 14 Jul 1992 17:43:48 GMT

In article <[e-mail]> [e-mail] (David Peterson) writes:
>From: [e-mail] (David Peterson)
>Subject: Debugger for daemons?
>Date: 9 Jul 1992 14:01:50 -0700


>Is there a source-level debugger (or something I can do to SADE
>or SourceBug) that will let me debug faceless background apps?

>I can start the thing in SourceBug and set breakpoints, but when
>I try to single step all the windows go blank and I can't tell
>whats going on.

>SADE won't even launch a daemon.

>Thanks,
>-dave.

Try Nosy/The Debugger from Jasik Designs (depending on your development
system, this should work with everything.

- -Christoph
[e-mail]

Christoph P. Sold                   CATS Software GmbH
                                    Mussbacher Landstr.2
                                    W-6730 Neustadt (Weinstrasse)
[e-mail]     Germany

"If an apple is fun, what the heck is an appletree?"

---------------------------

Organization: Carnegie Mellon, Pittsburgh, PA
Date: Sun, 12 Jul 1992 18:06:16 -0400
From: Brian Campbell <[e-mail]>
Subject: Dragging Icons...HELP!

    I am currently writing code (in Think C) for a graphical user
interface on the Mac.  The program is for mechanical (dynamic) system
modeling (i.e., it's a circuit simulator).  I currently have the core of
the program done... the user selects a tool (mass, spring, damper, etc)
from a tool palette, plots it down in in a grid, clicks on the icon's
handles, and makes connections.

    I am now to the point where I need to make the program more user
friendly (by conforming to the Mac User Interface Guidelines), and I
would like to be able to click on an icon (defined as a resource) with
the pointer (from the tool palette) and drag it to a new location (the
standard Mac click & drag).  The pointer should drag the outline of the
icon as well as the connecting lines to the other icons.  Unfortunately,
I cannot find a book that explains how to do this, so I was hoping that
someone out in net-land could help me.

    An example of source code that performs a similar function would be ideal.

Thanks in advance.

******************************************************************************
Brian
[e-mail] (until 8/14)
[e-mail] (permanent)

+++++++++++++++++++++++++++

From: Andreas Wuertz <[e-mail]>
Organization: Swiss Federal Institute of Technology, TIK
Date: Tue, 14 Jul 1992 11:54:27 GMT

In article <[e-mail]> Brian Campbell,
[e-mail] writes:
>standard Mac click & drag).  The pointer should drag the outline of the
>icon as well as the connecting lines to the other icons.  Unfortunately,
>I cannot find a book that explains how to do this, so I was hoping that
>someone out in net-land could help me.

Since 32-Bit QD there is a trap called BitmapToRgn or so. Do this with
icon's bitmap, add the other items (OpenRgn and then draw all items, the
CloseRgn, then UnionRgn with the icon's region). Then DragGrayRgn
(windowmgr, i think) to drag the outline around. If you want to support
macs/systems without 32-bit QD (built into sys 7), you can get a linkable
object of BitmapToRgn from DTS (developper technical support).

Hope this helps.  Andy

Andy from TIK

=======================================================
The earliest time for a program to be bug-free is,
when it's out of date. The latest time for a programmer
to retire is, when he writes such a program.
=======================================================

---------------------------

From: [e-mail] (Paul Robichaux)
Subject: DSAT error #28, ThinkPascal, and MacsBug (weird)
Date: 10 Jul 92 13:58:49 GMT
Organization: New Technology, Inc.

I've been developing a Think Pascal-based application at home, and
have finally gotten it to work well enough to make a standalone
version.

Lo and behold: when I fired it up this morning, I was suddenly
staring at MacsBug, which was complaining of a system error 28 - the
infamous heap/stack collision.

Here's a code fragment showing where the error occurs:

procedure ReadMyDataFile (aFile: FSSpec;
            var aList: MyDataListRec;
            refNum: integer);

var
    numBytes: longint;
    aMyData: MyDataHandle;
    tempMyData: MyDataDataRec;
    recSize, idx: integer;
    anErr: OSErr;
    tempRunData: testDataArray;
    ok: boolean;

begin
    debugStr('In ReadMyDataFile.;ATRA');

    { when I issue a 'g' in macsBug, I crash before reaching this line }
    anErr := SetFPos(RefNum, fsFromStart, 0);

    { I never see this line here! }
    debugStr('back from SetFPos.');

    if anErr = noErr then
    begin
      ...
      ...

MacsBug comes up with the debugStr message, and acknowledges that A-trap
recording is on. Subsequent use of the 's' command admits that 'step (into)'
was executed, then boom:

    system error #28 at 4080A2C6  _VRemove + 0046

Using ATP doesn't help, since no traps were recorded. I can't for the life of
me figure out why SetFPos would cause a heap collision.

Another oddity: using 'hc' after the system error asserts that the app heap
is OK. Does this mean that my system heap is broken? What the hell can I do
about _that_?

Any and all comments (even those including the phrase "every *real* Mac
programmer knows that...") are welcome. I'll post a summary once I either find
the fix or get help from the net.


Bewitched, bewildered, and _definitely_ bothered,
- -Paul
- --
Paul Robichaux, KD4JZG          | NTI doesn't pay for my opinions, and NASA
[e-mail]   | doesn't know I have any.
         This message printed on recycled phosphors.

+++++++++++++++++++++++++++

From: [e-mail] (Rich Siegel)
Date: 10 Jul 92 14:35:09 GMT
Organization: GCC Technologies

In article <[e-mail]> [e-mail] writes:
>I've been developing a Think Pascal-based application at home, and
>have finally gotten it to work well enough to make a standalone
>version.
>
>Lo and behold: when I fired it up this morning, I was suddenly
>staring at MacsBug, which was complaining of a system error 28 - the
>infamous heap/stack collision.
>
>Here's a code fragment showing where the error occurs:
>
>procedure ReadMyDataFile (aFile: FSSpec;
>            var aList: MyDataListRec;
>            refNum: integer);
>
>var
>    numBytes: longint;
>    aMyData: MyDataHandle;
>    tempMyData: MyDataDataRec;
>    recSize, idx: integer;
>    anErr: OSErr;
>    tempRunData: testDataArray;
>    ok: boolean;

Depending on the size of "tempRunData", you may be trying to allocate too
much on the stack. The reason this works at home and not at work is because
your home machine is probably a Color Quickdraw-capable machine, which
has a larger default stack size, and your machine at work is not. If
you bump up the stack size setting in the Run Options dialog, this will
be incorporated into the built application.

.
- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Software Engineer & Toolsmith
GCC Technologies

+++++++++++++++++++++++++++

From: [e-mail] (Paul Robichaux)
Date: 10 Jul 92 15:04:52 GMT
Organization: New Technology, Inc.

In <[e-mail]> [e-mail] (Rich Siegel) writes:
>Depending on the size of "tempRunData", you may be trying to allocate too
>much on the stack. The reason this works at home and not at work is because
>your home machine is probably a Color Quickdraw-capable machine, which
>has a larger default stack size, and your machine at work is not. If
>you bump up the stack size setting in the Run Options dialog, this will
>be incorporated into the built application.

I guess I was unclear (not the first time, either :) about my
configuration. This app has only been run on my home machine
(IIci/5/520 with a Futura SX card), and I have the zone size at 768k
and the stack size at 384k (last time I looked, anyway.) I'll bump it
up and adjust the SIZE resource and try again.

Since you're here, Rich :) - why doesn't this behavior appear in the
TP environment?

- -Paul
- --
Paul Robichaux, KD4JZG          | NTI doesn't pay for my opinions, and NASA
[e-mail]   | doesn't know I have any.
         This message printed on recycled phosphors.

+++++++++++++++++++++++++++

From: [e-mail] (Rich Siegel)
Organization: GCC Technologies
Date: Fri, 10 Jul 1992 17:18:12 GMT

In article <[e-mail]> [e-mail] writes:

>why doesn't this behavior appear in the
>TP environment?

because under the environment, the space allocated for the program to run
in is the sum of the stack and zone sizes. The system only allocates space
for your program based on the SIZE resource, which has to take into
account that sum.

You would be well-advised to reconsider your stack size requirements,
and perhaps allocate your local buffer dynamically. With a few exceptions,
there's usually not much reason to need more than about 32K of stack.

R.

- --
- -----------------------------------------------------------------------
Rich Siegel                              Internet: [e-mail]
Software Engineer & Toolsmith
GCC Technologies

+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Organization: Symantec Corp.
Date: Sat, 11 Jul 1992 14:00:03 GMT

>>>>> On Fri, 10 Jul 1992 14:35:09 GMT, [e-mail] (Rich Siegel) said:

 > If you bump up the stack size
 > setting in the Run Options dialog, this will be incorporated into
 > the built application.

Unless you're using $I-. If you turn off Pascal's initializations,
then you will get the Run Options stack in Pascal, but you will not
get it in the built app. If you need to use $I-, then you'll have to
adjust the stack yourself using SetApplLimit
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

+++++++++++++++++++++++++++

From: [e-mail] (Phil Shapiro)
Organization: Symantec Corp.
Date: Sat, 11 Jul 1992 14:01:59 GMT

>>>>> On Fri, 10 Jul 1992 14:35:09 GMT, [e-mail] (Rich Siegel) said:

 > If you bump up the stack size setting in the Run Options dialog,
 > this will be incorporated into the built application.

Unless you're using $I-. If you turn off Pascal's initializations,
then you will get the Run Options stack in Pascal, but you will not
get it in the built app. If you need to use $I-, then you'll have to
adjust the stack yourself using SetApplLimit. I believe that the TCL
has code to adjust the stack, if you're looking for an example.

    -phil
- --
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]

---------------------------

From: [e-mail] (Elliotte Rusty Harold)
Subject: When to HLock (and not HLock) handles
Date: 11 Jul 92 21:14:37 GMT
Organization: New Jersey Institute of Technology


    When should I and when shouldn't I lock a handle?  I gather that if
I'm going to do something like myPointer = *myHandle I should
HLock(myHandle) and keep it locked until I'm finished with myPointer.
However I'm using the technique described in Stephen Chernicoff's Mac
Revealed Vol II to store a handle to a structure containing all sorts of
information about a window's contents in the window's RefCon field.  The
window data structure contains, ints, booleans, and an array of pointers to
chars, i.e. a two-dimensional array of chars.  In particular when  I want
to do something like

    dataHandle = (WDHandle) GetWRefCon(gLifeWindow);
    myArray = (**dataHandle).structArray;

do I need to lock dataHandle before I start doing things to myArray?
And, since myArray is a pointer to a pointer, i.e. a handle, am I
ever going to need to lock it down or will the Memory Manager leave it
alone since it was not created by NewHandle but instead was
initially declared as an array of pointers each one of which was
separately allocated.

Elliotte Rusty Harold        Department of Applied Mathematics
[e-mail]        New Jersey Institute of Technology
[e-mail]        Newark, NJ 07103

+++++++++++++++++++++++++++

From: [e-mail] (David Fry)
Date: 12 Jul 92 04:25:32 GMT
Organization: Harvard Math Department

In article <[e-mail]> [e-mail] (Elliotte Rusty Harold) writes:
>
>    When should I and when shouldn't I lock a handle?  I gather that if
>I'm going to do something like myPointer = *myHandle I should
>HLock(myHandle) and keep it locked until I'm finished with myPointer.

That's basically it.  But you only need to do this if memory might
move, and try not to keep your handle locked longer than necessary.

>However I'm using the technique described in Stephen Chernicoff's Mac
>Revealed Vol II to store a handle to a structure containing all sorts of
>information about a window's contents in the window's RefCon field.  The
>window data structure contains, ints, booleans, and an array of pointers to
>chars, i.e. a two-dimensional array of chars.  In particular when  I want
>to do something like
>
>    dataHandle = (WDHandle) GetWRefCon(gLifeWindow);
>    myArray = (**dataHandle).structArray;
>
>do I need to lock dataHandle before I start doing things to myArray?

Think about it this way.  The data in your structure is somewhere in
memory.  As the Mac goes about its business, this data may be shuffled
about.  But the values won't change, of course.  All myArray is one
piece of data from that structure, so no matter how the memory moves,
myArray won't change.

A problem would occur if you did this:

    dataHandle = (WDHandle) GetWRefCon(gLifeWindow);
    dataPtr = *dataHandle;

If memory moves after this, a call to (dataPtr->structArray)[2][3]
(for instance) might be invalid because the value dataPtr now points to
something else.

>And, since myArray is a pointer to a pointer, i.e. a handle, am I
>ever going to need to lock it down or will the Memory Manager leave it
>alone since it was not created by NewHandle but instead was
>initially declared as an array of pointers each one of which was
>separately allocated.

If the memory is not allocated by NewHandle (or a Toolbox routine that
calls NewHandle), the memory manager will never move it. Your 2D array is
safe. A handle is a pointer to a pointer, but a Handle is something
allocated by the memory manager.

David Fry                                  [e-mail]
Division of Applied Sciences               [e-mail]
Harvard University                      ...!harvard!huma1!fry
Cambridge, MA  02138

---------------------------

End of C.S.M.P. Digest
**********************